ci: unbind the Dagster deploy from the production environment - #859
Merged
Conversation
The `production` GitHub environment now requires review from the deployers team, with self-review prevented, so applying a data migration to production takes two people. Irreversibility is the reason: a migration that deletes rows has no downgrade, only a restore. That environment is shared, so the gate also covers production API releases, which is intended -- release-please already makes releasing a decision, and this adds one approval to it. It would also have covered the Dagster code location deploy, which is not intended. That job reads only repository-level DAGSTER_CLOUD_API_TOKEN and DAGSTER_CLOUD_ORGANIZATION_ID, none of the environment's secrets, and it runs on every push to staging touching the code location. Binding it would have put an approval gate on routine merges -- a gate on the wrong thing, since it publishes code rather than data. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
Coverage✅ 77.96% total — gate is 75%. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Settings change, already applied
The
productionGitHub environment now requires review from the deployersteam, with self-review prevented:
{"type":"required_reviewers","reviewers":["deployers"],"prevent_self_review":true}So applying a data migration to production takes two people. Irreversibility is
the reason — a migration that deletes rows has no downgrade, only a restore.
deployershas four members, so requiring a second person will not deadlock.Why this code change goes with it
That environment is shared by three workflows. The gate now also covers
production API releases (
CD_production.yml), which is intended: release-pleasealready makes releasing a decision, and this adds one approval to it.
It would also have covered
CD_dagster_prod.yml, which is not intended.That job reads only repository-level
DAGSTER_CLOUD_API_TOKENandDAGSTER_CLOUD_ORGANIZATION_ID— none of the environment's secrets — and sinceit was retargeted it runs on every push to
stagingtouching the codelocation. Binding it would have put an approval gate on routine merges: a gate
on the wrong thing, since it publishes code rather than data.
Verified before removing it that the job consumes nothing environment-scoped.
The environment's own secrets (
CLOUD_SQL_*, deploy service account keys,SESSION_SECRET_KEY) remain in use by the two workflows that need them.Effect
CD_production.yml(API release)CD_dagster_prod.yml(code location)🤖 Generated with Claude Code